Controller Area Network (CAN) increasingly found its way into aerospace applications because of its cost effective and efficient networking capability for systems employing the Line-replaceable unit (LRU) concept to share data across a common media. The ability of CAN to transmit data, across a shared shielded twisted pair cable, has advantages in terms of weight savings at the aircraft integration level. Additionally, the CAN physical layer protocol specification provides error recovery and protection mechanisms that make this data bus standard attractive to aviation applications. Newer commercial air transport aircraft like the Airbus A380 or the Boeing 787 already accommodate between 50 and 250 CAN networks for all sorts of functions including flight deck systems, engine control and flight control systems. In an effort to provide a common standard for the use of CAN in commercial air transport, Airbus and Boeing initiated the CAN Technical Working Group of the Airlines Electronic Engineering Committee to define the ARINC specification 825. The target of ARINC 825 is to ensure interoperability and to simplify interoperation of CAN subsystems with other airborne networks for all classes of aircraft including the commercial air transport segment. The CAN Technical Working Group initially consisted of members from Airbus, Boeing, Rockwell Collins, GE Aerospace and Stock Flight Systems ([1]) and published the ARINC 825 specification [1] in November, 2007 with supplement 1 being released by May, 2010[2]. The ARINC specification 825 was influenced by the CANaerospace standard to a high degree.
Current commercial air transport aircraft system architectures have incorporated CAN as an ancillary subsystem bus to ARINC Specification 664, Part 7 (AFDX), networked Integrated Modular Avionics (IMA) architectures. For these aircraft, CAN has been used to link sensors, actuators and other types of avionics devices that typically require low to medium data transmission volumes during operation. In this role, CAN complements higher capacity networks that support systems controlling the flight deck information flow and presentation. In contrary, General Aviation system architectures employ CAN as one of the major avionics buses or even as the avionics backbone network. In this role CAN may have to fulfill all requirements of a flight safety critical network. The ARINC Specification 825 enhances CAN to create a network that embraces both philosophies. It may be used as a primary or ancillary avionics network and was designed to meet the following requirements:
To ensure interoperability and reliable communication, ARINC 825 specifies the electrical characteristics, bus transceiver requirements and data rates with the corresponding tolerances based on ISO 11898. The bit timing calculation (baud rate accuracy, sample point definition) and robustness to electromagnetic interference are given special emphasis. Also addressed within ARINC 825 are CAN connector and wiring considerations. The data rates supported by ARINC 825 are 1000 kbit/s, 500 kbit/s, 250 kbit/s, 125 kbit/s and 83.333 kbit/s.
ARINC 825 is entirely based on CAN 2.0B using extended frames (29-bit identifiers) which provide an adequate number of bits to divide the identifier into several sub-fields. These sub-fields are key issues in employing the identifier bits not only for the data object identification and transmission prioritization inherent to CAN but also for the purpose of creating a standardized application layer. CAN communication using 11-bit identifiers may coexist on an ARINC 825 bus if it is free of potential deadlock scenarios caused by single source bus masters.
The communication mechanisms of ARINC 825 are derived from the corresponding CANaerospace mechanisms. Just like CANaerospace, ARINC 825 defines additional ISO layer 3, 4 and 6 functions to support logical communication channels, one-to-many/peer-to-peer communication and station addressing. To accomplish this, the 29-Bit CAN identifier is given a special structure for ARINC 825 (see Figure 1). Logical Communication Channels (LCCs) provide these independent layers of communication (see Figure 2).
To support interoperability in airborne systems, ARINC 825 includes:
The aircraft function definitions used to identify source and destination of messages are derived from the Air Transport Association (ATA) aircraft system chapters. This helps system engineers to assign the proper functions for their systems based on definitions well known in aeronautics since decades.
ARINC 825 adopted the CANaerospace bandwidth management concept known as "Time Triggered Bus Scheduling". This concept provides a means of computing the bus load based on the number of messages in a network segment and adjusting their transmission rates. Bandwidth management minimizes peak load scenarios and jitter caused by the CAN bus arbitration. Applying this concept, it can be demonstrated that ARINC 825 networks behave predictably and are able to fulfill the requirements for flight safety critical systems. For ensuring this under fault conditions the system designer has to define the behaviour under these conditions (such as high occurrence of error frames and avoidance of priority inversion) [3].
ARINC 825 may be used for systems classified up to Design Assurance Level (DAL) A if the effect of the loss of one bus does not present a hazard exceeding the classification "major". Figure 3 shows an example of two ARINC 825 nodes operating in accordance with the Time Triggered Bus Scheduling concept.
ARINC 825 uses a communication profile database for the description of integrated networks. A communication profile is created for each LRU in a human readable file format, since supplement 1 based on XML 1.0[2]. The combination of all LRU communication profiles for a given network describes the entire bus traffic and provides a valuable means for specification and verification of ARINC 825 networks. An analysis of the communication profile database allows to detect potential network problems at an early stage. ARINC 825 test tools must be able to read the communication profile database and interpret network data accordingly.
Commercial air transport aircraft Integrated Modular Avionics system architectures use multiple networks with different characteristics which have to exchange data with each other using gateways. Typically, bandwidth and communication principles of the involved networks differ widely. To support the design of gateways between CAN and other networks, ARINC 825 specifies a gateway model and provides substantial information about protocol conversion, bandwidth management, data buffering and fault isolation.
The ARINC specification 825 contains a design guidelines section that helps system engineers and CAN LRU designers to implement ARINC 825 properly and in a certifiable manner. This section is intended to document industry experience that led to the decisions in the ARINC Specification 825. The guidelines are general network design criteria to be considered when designing an ARINC 825 network; they are not requirements but rather the recommendations to avoid potential design traps a network designer may encounter.
The consistency and integrity of the ARINC specification 825 was continuously verified during the standardization process using a reference hardware/software system [2]. The Airlines Electronic Engineering Committee decided that all future ARINC specifications using CAN (i.e. the ARINC 826 Data Load and ARINC 812 Galley Insert Communication Standards) shall be based on ARINC 825. Airbus Technical Design Directives already specify ARINC 825 for many systems of the new Airbus A350. CANaerospace continues to coexist with ARINC 825 as the "11-bit identifier alternative" and provides enhanced ARINC 825 compatibility starting with revision 1.8.
Standards
As of this edit, this article uses content from "ARINC 825", which is licensed in a way that permits reuse under the Creative Commons Attribution-ShareAlike 3.0 Unported License, but not under the GFDL. All relevant terms must be followed.